home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group98c.txt / 000037_icon-group-sender _Wed Sep 16 16:46:55 1998.msg < prev    next >
Internet Message Format  |  2000-09-20  |  5KB

  1. Return-Path: <icon-group-sender>
  2. Received: from kingfisher.CS.Arizona.EDU (kingfisher.CS.Arizona.EDU [192.12.69.239])
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) with SMTP id QAA10662
  4.     for <icon-group-addresses@baskerville.CS.Arizona.EDU>; Wed, 16 Sep 1998 16:46:55 -0700 (MST)
  5. Received: by kingfisher.CS.Arizona.EDU (5.65v4.0/1.1.8.2/08Nov94-0446PM)
  6.     id AA05606; Wed, 16 Sep 1998 16:46:26 -0700
  7. To: icon-group@optima.CS.Arizona.EDU
  8. Date: 16 Sep 1998 15:27:22 -0400
  9. From: richard@goon.stg.brown.edu (Richard L. Goerwitz III)
  10. Message-Id: <6tp3eq$buu@goon.stg.brown.edu>
  11. Organization: Brown University Scholarly Technology Group
  12. Sender: icon-group-request@optima.CS.Arizona.EDU
  13. References: <9809120038.AA13184@hawk.CS.Arizona.EDU>
  14. Subject: Re: Unicode support or support for non-ASCII based character ma
  15. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  16. Status: RO
  17.  
  18. Re Unicode, Gregg Townsend  <gmt@baskerville.CS.Arizona.EDU> wrote:
  19.  
  20. >    --    In Unicode, there aren't just 26 lower-case letters, and
  21. >    they're not all contiguous.  What should &lcase contain?
  22. >    How would this affect existing programs?
  23.  
  24. It's funny that this issue has raised its ugly head again.  I
  25. guess it was four or five years ago that I advocated moving to
  26. Unicode (the logic was that Icon was a good string processing
  27. language, and that it was kind of silly to confine it to an 
  28. eight-bit universe).
  29.  
  30. The problem with doing this back then was one of resources (the
  31. Icon Project was winding down, and graphics had become the main
  32. concern).  Users had some good spats over Unicode, but ultimately
  33. nobody had any resources to bring it off - and some prominent
  34. members of the Icon community denied that Unicode would ever be-
  35. come a prominent standard (aside: sixteen-bit characters are now
  36. the default for NT; Java also works on the same assumption; and
  37. Unicode is the core format for XML, too).
  38.  
  39. Anyway, aside from me annoying everyone with my Unicode "mantra"
  40. (as Clint called it once), the issue pretty much went away.
  41.  
  42. To the questions you raised (re lowercase letters, affect on
  43. existing programs):
  44.  
  45. The number of alphabets with case distinctions is finite, and in
  46. fact rather low (Latin, Greek, Coptic, Armenian, and Cyrillic).
  47. So you define everything (except specifically uppercase letters
  48. in these scripts) to be lowercase.  Then you define everything
  49. (except specifically lowercase letters in these scripts) to be
  50. uppercase.
  51.  
  52. Note that in some languages the number of lowercase letters ex-
  53. ceeds the number of uppercase letters (and the mappings are not
  54. one-to-one).  But in most cases, reasonable equivalents can be
  55. conjured up.
  56.  
  57. I'd be happy to contribute code, if it comes to that.
  58.  
  59. As for how this would affect existing programs:  Heavily.  The
  60. assumption of Unicode characters really screws up everything.  Not
  61. only do you have to worry about upper/lowercase mapping, but you
  62. also have to think about (as GT notes above) I/O.
  63.  
  64. Some ideas:
  65.  
  66.   0) data and character streams should be read using different
  67.      functions
  68.   1) user should be permitted to select a (default) input format
  69.      (e.g., ISO 8859-1, UTF-8, UTF-16, etc.) for character
  70.      stream readers
  71.   2) user should be permitted to select a (default) output format
  72.      (e.g., ISO 8859-1, UTF-8, UTF-16, etc.) for character
  73.      stream writers
  74.   3) all internal strings must be represented as UCS-2 (or UCS-4,
  75.      if you don't care about memory); you can't use UTF-8, because
  76.      multi-byte variable-length characters are no good for any
  77.      code that relies on fixed-width characters
  78.  
  79. For most programs, the user would just select ISO 8859 as the
  80. default character input and output format.
  81.  
  82. The whole thing is a mess, and my guess is that unless there is
  83. a new source of funding for Icon - and an effort to put in a
  84. ground-up rewrite - it would not be feasible to rearrange every-
  85. thing to support Unicode.
  86.  
  87. If it does happen, I suspect that it will happen in a descendant
  88. language that incorporates fundamental features like networking.
  89. Two years ago or so I saw some excellent networking extensions to
  90. Icon posted here, incidentally.  Seemed to me they gave Icon a
  91. fighting chance.
  92.  
  93. What ever became of them?
  94.  
  95. One other thing to think about:  What will the PERL community so
  96. on the Unicode/XML front?  Keep your eyes peeled.
  97.  
  98. -- 
  99.  
  100. Richard Goerwitz
  101. PGP key fingerprint:    C1 3E F4 23 7C 33 51 8D  3B 88 53 57 56 0D 38 A0
  102. For more info (mail, phone, fax no.):  finger richard@goon.stg.brown.edu
  103.